Skip to main content

How tiCrypt Isolates Virtual Machines at the Network Level

· 7 min read
Thomas Samant
Thomas Samant

How tiCrypt Isolates Virtual Machines at the Network Level

Secure virtual machines in tiCrypt run in near-complete isolation from each other and from the surrounding environment. This isolation is the foundation of tiCrypt's security model. Every network pathway into or out of a VM is tightly controlled, authenticated, and encrypted — with no exceptions.

This post explains the mechanisms that make this possible: proxy-mediated communication, application port tunneling, VM-level network isolation, and controlled access to external licensing servers.

Key Components​

Several tiCrypt components participate in VM network security. Understanding their roles makes the rest of the post easier to follow:

  • ticrypt-connect — The application running on the user's device.
  • ticrypt-frontend — The browser-based interface, served by ticrypt-connect.
  • ticrypt-backend — The set of tiCrypt services running on the backend server.
  • ticrypt-rest — The REST-based entry point into ticrypt-backend.
  • ticrypt-proxy — Mediates communication between components by replicating traffic between two separate connections.
  • ticrypt-allowedlist — Controls access to external licensing servers.
  • ticrypt-vmc — The VM controller, responsible for all security mechanisms within the secure VM.

How VM Communication Works​

tiCrypt VMs do not accept direct connections. All ports are blocked except port 22, and even that port is not running SSH — it is controlled entirely by ticrypt-vmc for traffic tunneling. There is no mechanism to contact a secure VM through direct access.

Instead, all communication is mediated by ticrypt-proxy using the following sequence:

  1. The ticrypt-vmc maintains a persistent WebSocket connection to ticrypt-proxy.
  2. When a user wants to connect, ticrypt-frontend opens a matching WebSocket through ticrypt-proxy.
  3. ticrypt-proxy replicates traffic between the two WebSocket connections.
  4. ticrypt-vmc immediately creates a new WebSocket for future connections.
  5. Both the frontend and the VM controller exchange digital signature proofs of identity and negotiate a shared secret via Diffie-Hellman key exchange.
  6. If the digital signature fails or the user is not authorized, the connection is immediately closed. Likewise, if the VM's validation fails, ticrypt-frontend closes the connection.
  7. All subsequent messages in both directions are encrypted with the negotiated key.

After the initial handshake, all traffic is hidden from ticrypt-proxy and every other part of the infrastructure. Commands, terminal data, keystrokes — everything travels through this encrypted channel.

The only message sent in the clear is the initial authentication and key negotiation message. Any other message or operation is rejected outright.

Communication does not rely on listening on standard ports and can only be mediated by ticrypt-proxy. The VM owner's public key cannot change once learned by ticrypt-vmc, meaning that hijacking the communication would require compromising the user's private key.

Most VM functionality operates exclusively through this proxy-mediated channel. The only exception is application port tunneling.

Application Port Tunneling​

To support rich application deployment inside VMs, tiCrypt provides a generic mechanism for tunneling TCP traffic on specific ports from the VM to the user's device. The mechanism is highly controlled, but in principle it can make any network application accessible — for example, RDP over port 3389. Multiple ports are typically forwarded simultaneously to support broader functionality.

Application tunneling works similarly to SSH reverse port forwarding, but uses TLS instead of SSH. Access to VMs is limited to port 22 — not SSH as a service. ticrypt-connect mediates the forwarding with ticrypt-vmc listening on port 22.

Setting Up a Tunnel​

Initiating a forwarding tunnel involves several coordinated steps:

  1. The ticrypt-frontend, using an authenticated session, tells ticrypt-rest to create a pathway to a specific VM.
  2. The request is validated and ticrypt-proxy is informed.
  3. ticrypt-proxy sets up a listening endpoint on one of the designated ports (typically 6000–6100). The endpoint is strictly scoped and only accepts connections from the IP address that made the request.
  4. ticrypt-frontend receives the allocated port.
  5. ticrypt-frontend asks ticrypt-connect to generate a TLS certificate for authentication and encryption.
  6. ticrypt-frontend tells ticrypt-vmc to accept the application forwarding and provides the TLS certificate.
  7. ticrypt-vmc replies with a list of ports that need to be tunneled.
  8. ticrypt-frontend instructs ticrypt-connect to start the connection using the certificate.
  9. Upon connection, ticrypt-vmc verifies the digital signature and initiates TLS-mediated tunneling.
  10. Traffic to and from the local port on the user's device is tunneled and recreated inside the VM, enabling application access.

A special case exists for SFTP over port 2022, if the feature is enabled in ticrypt-vmc. This can be used to transfer large amounts of data from the user's device to the VM.

The Communication Pathway​

Once established, the tunnel follows this path:

  1. ticrypt-connect accesses the allocated port controlled by ticrypt-proxy. The connection is pinned to the originating IP address.
  2. ticrypt-proxy forwards the request to the VM host endpoint.
  3. The VM host forwards traffic to port 22 of the correct VM.
  4. ticrypt-vmc listens on port 22 and runs the TLS protocol with port tunneling.

Port 22 is specifically chosen to prevent an SSH server from being deployed in its place. The traffic on port 22 is the TLS protocol under ticrypt-vmc control — not the SSH protocol.

The entire pathway is secured with TLS encryption and authenticated with digital signatures. At no point can any intermediate component intercept the communication without breaking TLS.

VM Network Isolation​

To ensure security, only port 22 is open inbound on secure VMs. All outbound traffic is restricted to communication with ticrypt-rest, unless an exception is granted through the ticrypt-allowedlist mechanism.

The isolation is enforced through multiple layers:

  • Internal blocking — All traffic to ports other than 22 is blocked internally by the VM itself, isolating any other access. Application access is provided exclusively through the port tunneling mechanism described above.
  • Host-level firewall — All traffic to the VM's IP on ports other than 22 is blocked by firewall rules on the VM host.
  • No external routing — The VM host does not route external traffic to VMs, with the sole exception of port 22.
  • Outbound blocking — All outbound traffic from VMs is blocked unless the ticrypt-allowedlist mechanism is in use.

The mechanism that enables access on port 22 while blocking everything else works by preventing all traffic routing and instead providing a forwarding path from a specific port range on the VM host to port 22 of the IP ranges dedicated to secure VMs. There is no way for a server outside the specific VM host to access any other VM port.

Outbound traffic from secure VMs is blocked because it could be used to exfiltrate data, resulting in data breaches.

Licensing Server Access​

Most commercial software requires access to external licensing servers. These servers typically reside within the organization, but occasionally they are external. tiCrypt provides a strictly controlled mechanism for enabling this access without compromising VM isolation.

The ticrypt-allowedlist component mediates access by manipulating two things:

  • Firewall and port forwarding rules on the server running ticrypt-backend.
  • DNS replies to requests originating from VMs.

The mechanism is precise: unless a specific mapping is configured using ipsets and firewall rules, all outgoing traffic from VMs remains blocked. The ticrypt-allowedlist component works in conjunction with ticrypt-frontend to provide a convenient interface for enabling and disabling access. This capability requires SuperAdmin privileges.

Defense in Depth​

No single mechanism secures a tiCrypt VM. Instead, multiple independent layers — proxy-mediated communication, TLS-authenticated tunneling, internal and host-level firewalls, outbound traffic blocking, and controlled DNS — work together to create an environment where VMs are effectively unreachable except through authenticated, encrypted, and auditable channels. Each layer is designed so that even if one were bypassed, the remaining layers would continue to protect the VM and its data.